Internet Info 1994 March

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / iesg / iesg.91-09-19 < prev next >

Wrap

Text File | 1993-02-04 | 13KB | 356 lines

IETF STEERING GROUP (IESG) REPORT FROM THE TELECONFERENCE SEPTEMBER 19TH, 1991 Reported by: Greg Vaudreuil, IESG Secretary This report contains - Meeting Agenda - Meeting Attendees - Meeting Notes Please contact IESG Secretary Greg Vaudreuil (iesg-secretary@nri.reston.va.us) for more details on any particular topic. Attendees Almquist, Philip / Consultant Callon, Ross / DEC Chiappa, Noel Coya, Steve / CNRI Crocker, Steve / TIS Davin, Chuck / MIT Estrada, Susan / CERFnet Gross, Philip / ANS Hinden, Robert / BBN Hobby, Russ / UC-DAVIS Stockman, Bernard / SUNET/NORDUnet Vaudreuil, Greg / CNRI Regrets Borman, David / CRAY Crocker, Dave / DEC Reynolds, Joyce / ISI Agenda 1) Administrivia - Bash the Agenda - Review of the Minutes - Next Meeting - Distinguished names - Next IESG Teleconference 2) Protocol Actions - Approve recommendations - Bridge MIB - DECNet Phase IV MIB - Remote LAN Monitoring MIB - FDDI MIB - X500 and Domain Names - Interim Approach to Network Addresses - X.500 Replication Requirements - X.500 Replication Extensions - X.500 Schema - OSI Directory for User Friendly Naming - String Encoding of Presentation Addresses - Criterion for Advancing Routing Protocols - Discuss status - Point to Point Protocol - Call Accounting - Border gateway Protocol 3) Technical Management - Discontinuous Subnets - Secure FTP Minutes ------- 1 Administrivia 1.1 Agenda Bashing The agenda was accepted as was mailed. 1.2 Minutes No action was taken on any of the many outstanding sets of minutes. 1.3 Next Meeting Distinguished name phone conference scheduled for September 26th. The agenda will be provided by Russ Hobby. Members on the IESG-TECH mailing list with the addition of Erik Huizer and Steve Kille should be invited to participate. The next IESG phone conference was scheduled for October 3rd. 2.0 Protocol Actions The review of pending protocol actions began with a review of the many MIBs up for consideration. A list of concerns was mailed the IESG list and is included as an Appendix. 2.1) Bridge MIB The Bridge MIB was submitted to the IESG as a proposed standard. The recommendation has been crafted, but since that time, interesting developments have occurred in IEEE. A new mostly stable version of the source-routing specification has been adopted. This renders some of the MIB objects in the SNMP MIB out of sync with the new version. This raises some questions as to whether the document should proceed to proposed standard, or be sent back to the Working Group for rework in light of the new IEEE work. It should be noted that the IEEE draft is not yet final version. ACTION: Davin, Gross, D. Crocker -- Determine the proper course of action to resolve the new conflict between the SNMP Bridge MIB and the IEEE Source Routing MIB. This action should include sending the liaison letter to the IEEE letter. 2.2) DECNet Phase IV MIB This MIB is aligned with all the appropriate documents from DEC. The IESG held approval of the MIB pending final text of the document. Action: Davin -- Get the final text of the Decnet Phase IV MIB to the Internet Drafts directory. 2.3) Remote LAN Monitoring MIB The IESG approved the recommendation of both the RMON MIB and the RMON trap MIB. While complex, these MIB is to be used only in special purpose, possibly dedicated, monitoring "boxes". ACTION: Vaudreuil -- Send the recommendation to publish the Remote Monitoring MIB as a proposed standard. 2.4) FDDI MIB The IESG approved this recommendation. This work is aligned with the ANSI Version 6.2 work. ACTION: Vaudreuil -- Send the recommendation to publish the FDDI MIB document as a proposed standard. The IESG proceeded to review the recommendation for the X.500 documents. 2.5) X.500 and Domain Names The IESG approved this recommendation. Action: Vaudreuil -- Send a the recommendation to publish X.500 and Domain Name document as an experimental protocol. 2.6) Interim Approach to Network Addresses The IESG approved this recommendation, but a final version of the document is needed from Steve Hardcastle-Kille. ACTION: Vaudreuil -- Send the recommendation to publish the Interim Approach to Network Addresses document as a proposed standard after a new version is posted as an Internet Draft. 2.7) X.500 Replication Requirements The IESG approved this recommendation. Action: Vaudreuil -- Send a the recommendation to publish the X.500 Replication Requirements document as an informational Document. 2.8) X.500 Replication Extensions The IESG approved this recommendation. Action: Vaudreuil -- Send a the recommendation to publish the X.500 Replication Extensions document as a proposed standard. 2.9) X.500 Schema The IESG approved this recommendation. Action: Vaudreuil -- Send a the recommendation to publish the X.500 Schema as a Proposed Standard. 2.10) OSI Directory for User Friendly Naming The IESG approved this recommendation. Action: Vaudreuil -- Send a the recommendation to publish the OSI Directory for User Friendly Naming as a Proposed Standard. 2.11) String Encoding of Presentation Addresses This recommendation was approved pending the insertion of text supplied by Phill Gross. This text describes the IESG position on the standardization of user interfaces. Further discussion is documented later in these minutes. Action: Vaudreuil -- Edit the recommendation to publish the String Encoding of Presentation Addresses document as a proposed standard and send to the IAB. Phill Gross's text on the standardization of user interfaces was a general purpose statement of IESG understanding. As such the IESG encouraged Phill to expand on the text with the intention of publication of this as an RFC. ACTION: Gross -- Elaborate on the User Interface Policy statement with the intention of publishing it as a RFC. 2.12) Criterion for Advancing Routing Protocols The IESG considered Bob Hinden's Routing Requirements document. This is an instance of a communication from the IESG documenting operational procedures. The IESG agreed that this document should be published as an Informational document. ACTION: Vaudreuil -- With Bob Hinden, craft a notification to the RFC Editor to publish the IESG criterion for Advancing Routing Protocols as an informational document. The following are protocol actions which have not yet been recommended by the IESG. 2.13) Point to Point Protocol The Working Group chairman of the PPP working group confirmed that there are multiple interoperable implementations of the PPP code, both in synchronous and asynchronous mode. The IESG also considered the lack of security provisions in the protocol, but were assured that the protocol had the appropriate "hooks" and that the PPP working group was working toward the security options. The only remaining issue was the inclusion of the original authors on the PPP document. It is not clear if all contributors should be listed or authors, or the current author be listed as an editor. ACTION: Chiappa -- Contact the author of the PPP documents and the chairman of the PPP working groups to clarify for the IESG the "lineage" of the current PPP documents with respect to their authorship. It is a tradition, but not a procedural necessity, to have protocols that are being considered for Draft Standards status to be presented to the IETF plenary for one last round of comments. In the next few months, there are expected to be a rather large number of these protocol actions, and the IESG would like to be able to clear some of these off the cue by electronic mail. To facilitate this, the IESG agreed to hold a weeks comment period before elevating the PPP protocol to Draft Standard. POSITION: Protocols which are being considered for Draft Standard status need a public review outside of the working group before being recommended to the IAB. This review traditionally occurs in the Open Plenary session of a IETF, however, this review may also be conducted by email on the IETF mailing list. ACTION: Coya -- Add the policy on review of Draft Standard protocols to the IETF handbook. ACTION: Vaudreuil -- Send in a note to the IETF announcing the pending elevation of PPP to Draft Standard. ACTION: Vaudreuil -- Craft a recommendation elevation the PPP document to Draft Standard. 2.14) Call Accounting Background Document The Call Accounting Working Group has finished a background document outlining the requirements of accounting services for the Internet. A final version will be sent to the Internet Drafts directory shortly. This document is for Informational purposed only. The IESG approved the publication of this document. ACTION: Vaudreuil -- Write and send a "notification" to the RFC editor after the final version of the Call Accounting document is posted in the Internet Drafts Directory. 2.15) Border Gateway Protocol The BGP usage document was sent the Internet Drafts Directory. The protocol is now ready for recommendation to the IAB. Steve Coya was unable to find a time for an IESG <=> teleconference before Interop. Gross has asked for this topic to be added to the IAB agenda for their Interop meeting and has requested that the IESG be invited for that topic session. To stimulate this discussion, Gross has asked that the recommendation be sent to the IAB prior to this meeting. ACTION: Vaudreuil -- Craft a recommendation to elevate BGP to Draft Standard. In this note, include each of the 5 documents in the BGP set. ACTION: Coya -- Send a note to the IAB explaining that the BGP teleconferencing effort was unsuccessful and will be discussed in a future meeting. 3) Technical Management Issues 3.1 Secure FTP There has been a proposal to make FTP more secure. Two approaches were suggested, 1) to authenticate the data path, and 2) add negotiation into the control channel. The IESG was not prepared to discuss these issues in depth, and tasked the Security and Applications Area Directors to act upon these proposals. ACTION: Crocker, Hobby -- Investigate the Secure FTP proposals, and either encourage their publication or form a working group to review these proposals. 4.2 Discontinuous Subnets At the last IETF meeting a recurring topic came up with some urgency. There are people who want to alter the nature of subnetting to allow new functionality and new topologies to be built. There are two primary issues. 1) There is a desire in large public networks to be able to connect different networks connected without a router. 2) There is a desire and the capability in the "modern" IGP's to allow subnets to become disconnected. A common example is a company having a single network number connected by a second distinct network. In the second case, there are two distinct situations. The first is discontinuous subnets within a single AS, and the other is discontinuous subnets across the broader network. From an engineering standpoint, the solution is already at hand for subnets within a single AS. Inter AS routing is a bit less settled, in particular, no EGP support the carrying of subnet masks. Several large architectural issues were raised in the IESG discussion. First, the current routing and addressing architecture is reaching it's limits. Any change in the current architecture should be accomplished with an eye to the new routing paradigm. It is not clear, but it seems likely that transition to the new paradigm may be higher if we allow discontinuous subnets. Both of these proposals result in removing the topological significance out of the subnet address. This has the effect of defeating one of the main arguments in favor of subnets, which was to add some hierarchy to the otherwise flat addressing space. If this happens, big things change. The IESG realized that this is a bigger issue than could be settled in the little time remaining in this teleconference. Further discussion was deferred until the face to face meeting planned for the week of Interop. ACTION: Coya -- Schedule a 4 hour meeting sometime for the week of Interop in a time when the most IESG members can attend. ACTION: IESG -- Reread the NSAP Assignment Guidelines document, and Chiappa's routing architecture message in preparation for the face to face meeting.